It has been long sought to generate a trusted connection to/with digital electronic devices located on residential, enterprise and office networks not being able to receive inbound connections which basically has three solutions:                1. manual router configuration with port forwarding;        2. UnPNP which is supported in residential and sometimes enterprise systems, but not supported at all on mobile systems. (see for example www.en.wikipedia.org/wiki/Carrier-grade_NAT); and        3. Use of persistent outbound connections, polling, and special event synchronization techniques most be employed in order for it to function.        
In a mobile environment connected on 3/4G there is no way to receive an inbound connection at all.
While cell phone provider networks provide Internet access for mobile end users, it is not allowed to connect to devices behind an NAT (network address translation) router, i.e. the devices are inaccessible for inbound TCP connections from the Internet.
Further prior art is contained in “Enabling Push-based Mobile Web Services for Today's Cell Phone Provider Networks” by Sascha Roth of the Department of Computer Science at Hochschule Darmstadt—University of Applied Sciences, Germany. (available at www.cscan.org/default.asp?page=openaccess&eid=2&id=128).
According to Bryan Ford Massachusetts Institute of Technology (available at www.brynosaurus.com/pub/net/p2pnat/) there are a few additional known methods of establishing connectivity between private devices (behind a NAT):                1. message relaying: the most reliable—but least efficient—method of P2P communication across network address translation (NAT) is simply to make the communication look to the network like standard client/server communication, through relaying. Suppose two client hosts A and B have each initiated TCP or UDP (user datagram protocol) connections to a well-known server S, at the global IP address 18.181.0.31 of S and port number 1234. As shown in FIG. 1 the clients reside on separate private networks, and their respective NATs prevent either client from directly initiating a connection to the other. Instead of attempting a direct connection, the two clients can simply use the server S to relay messages between them. For example, to send a message to client B, client A simply sends the message to server S along its already-established client/server connection, and server S forwards the message on to client B using its existing client/server connection with B.                    This is the method which is mostly employed today. The limitation of this method is knowledge of the “1234” port. The concept of a message suggests an existence of a higher level protocol, which can define message structure and syntax, otherwise the relay will not know when to stop reading data, as well as to which one of all the attached clients the data needs to be delivered to.            Either way, this method makes it impossible for one of the devices to be a standard based application such as a standard web browser, which makes usage of browser security impossible.            In addition, there are limitations to this technique due to mandating a single known open port, as well as both devices A and B are required to speak the same protocol. This limits the scope of such connection to only context of a given software application. Further limitations of message relaying are:                            Both devices need to know the endpoint of the servers.                Both devices need to know the public keys of the server (e.g. TeamViewer®).                Custom protocol needs to exist and therefore only applications implementing this protocol can connect. This rules out all existing software which includes a web browser as a solution to reaching the aforementioned object.                                                2. hole-punching: The inventors consider this not a reliable method, as it relies on weakness of the implementation of NAT, typically NAT on small size routers does not keep a table of connections but rather operates on port level. So when device A opens a connection to a well-known server, it inadvertently allocates a public port to that specific connection to be able to receive traffic from the original connection target. Now the known public server lets device b know what that port is, and now device B starts talking to device A.        3. universal plug-and-play—UnPnP this protocol relies on IP multicast messages, which is limited only to residential and small offices, as carriers use different NAT with different port allocation algorithms, and do not support UnPnP for transmission control protocol (TCP) connections.        
A connection between an application running in a browser stack, and an application in another browser stack or between a browser stack and a native mobile client in a secure manner that is secured end2end using native browser technologies is simply not possible with any of the technologies described above.
An outline of a prior art method for connection build-up is given by FIG. 1.
Panton T. et al., “Secure proximity-based identity pairing using an untrusted signalling service”, 2016 13TH IEEE ANNUAL CONSUMER COMMUNICATIONS & NETWORKING CONFERENCE (CCNC), IEEE, 9 Jan. 2016 (2016-01-09), pages 942-947, XP032887061, DOI: 10.1109/CCNC.2016.7444914 discloses a proximity-based pairing scheme that uses a signalling service to minimize the trust requirements on a third party, achieving anonymity and avoiding the need for a public key infrastructure, while still requiring only a simple asymmetric pairing protocol.
An object of the invention therefore is to provide a method of generating a secure connection to/with a digital electronic device located on a private network space.
Aspects of the present invention, examples and exemplary steps and their embodiments are disclosed in the following. Different advantageous features can be combined in accordance with the invention wherever technically expedient and feasible.